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USING A HIGH LEVEL PROGRAMMING processing 16, 32, or 64 bits of information or more with a 
LANGUAGE WITH A MICROCONTROLLER single instruction. In contrast to the microprocessor, a micro- 
controller includes a central processing unit, memory and 
Under 35 U.S.C. § 119(e), this application claims benefit other functional elements, all on a single semiconductor 
of prior U.S. provisional application Serial No. 60/029,057, 5 substrate, or integrated circuit (e.g., a "chip"). As compared 
filed Oct. 25, 1996. to the relatively large external memory accessed by the 
A portion of the disclosure of this patent document microprocessor, the typical microcontroller accesses a much 
contains material which is subject to copyright protection. smaller memory. Atypical microcontroller can access one to 
The copyright owner has no objection to the facsimile sixty-four kilobytes of built-in memory, with sixteen kilo- 
reproduction by anyone of the patent document or the patent io bytes being very common. 

disclosure, as it appears in the Patent and Trademark Office There are generally three different types of memory used: 

patent file or records, but otherwise reserves all copyright random access memory (RAM), read only memory (ROM), 

rights whatsoever. and electrically erasable programmable read only memory 

« . ™,-,^w,™ ^„ .vn^mnv, (EEPROM). In a microcontroller, the amount of each kind 

BACKGROUND OF THE INVENTION „ ^ memor / available - a constr ained by the amount of space 

This invention relates in general to the field of on the integrated circuit used for each kind of memory, 

programming, and more particularly to using a high level Typically, RAM takes the most space, and is in shortest 

programming language with a smart card or a microcontrol- supply. ROM takes the least space, and is abundant, 

ler. EEPROM is more abundant than RAM, but less than ROM. 

Software applications written in the Java high-level pro- 20 Each kind of memory is suitable for different purposes, 
gramming language have been so designed that an applica- Although ROM is the least expensive, it is suitable only for 
tion written in Java can be run on many different computer data that is unchanging, such as operating system code, 
brands or computer platforms without change. This is EEPROM is useful for storing data that must be retained 
accomplished by the following procedure. When a Java when power is removed, but is extremely slow to write, 
application is written, it is compiled into "Class" files 25 RAM can be written and read at high speed, but is expensive 
containing byte codes that are instructions for a hypothetical and data in RAM is lost when power is removed. A micro- 
computer called a Java Virtual Machine. An implementation processor system typically has relatively little ROM and 
of this virtual machine is written for each platform that is EEPROM, and has 1 to 128 megabytes of RAM, since it is 
supported. When a user wishes to run a particular Java not constrained by what will fit on a single integrated circuit 
application on a selected platform, the class files compiled 30 device, and often has access to an external disk memory 
from the desired application is loaded onto the selected system that serves as a large writable, non-volatile storage 
platform. The Java virtual machine for the selected platform area at a lower cost than EEPROM. However, a microcon- 
is run, and interprets the byte codes in the class file, thus trailer typically has a small RAM of 0. 1 to 2.0 K, 2K to 8K 
effectively running the Java application. of EEPROM, and 8K-56K of ROM. 

Java is described in the following references which are Due to the small number of external components required 

hereby incorporated by reference: (1) Arnold, Ken, and and their small size, microcontrollers frequently are used in 

James Gosling, "The Java Programming Language," integrated circuit cards, such as smart cards. Such smart 

Addison-Wesley, 1996; (2) James Gosling, Bill Joy, and Guy cards come in a variety of forms, including contact-based 

Steele, "The Java Language Specification," Sun cards, which must be inserted into a reader to be used, and 

Microsystems, 1996, (web site: http://java.sun.com/doc/ contactless cards, which need not be inserted. In fact, 

language_specification); (3) James Gosling and Henry microcontrollers with contactless communication are often 

McGilton, "The Java Language Environment: A White embedded into specialized forms, such as watches and rings, 

Paper," Sun Microsystems, 1995 (web site: http:// effectively integrating the functionality of a smart card in an 

java.sun.com/doc/language_environment/); and (4) Tim 45 ergonomically attractive manner. 

Lindholm and Frank Yellin, "The Java Virtual Machine Because of the constrained environment, applications for 

Specification," Addison-Wesley, 1997. These texts among smart cards are typically written in a low level programming 

many others describe how to program using Java. language (e.g., assembly language) to conserve memory. 

In order for a Java application to run on a specific The integrated circuit card is a secure, robust, tamper- 
platform, a Java virtual machine implementation must be 50 resistant and portable device for storing data. The integrated 
written that will run within the constraints of the platform, circuit card is the most personal of personal computers 
and a mechanism must be provided for loading the desired because of its small size and because of the hardware and 
Java application on the platform, again keeping within the software data security features unique to the integrated 
constraints of this platform. circuit card. 

Conventional platforms that support Java are typically 55 The primary task of the integrated circuit card and the 

microprocessor-based computers, with access to relatively microcontroller on the card is to protect the data stored on 

large amounts of memory and hard disk storage space. Such the card. Consequently, since its invention in 1974, inte- 

microprocessor implementations frequently are used in grated circuit card technology has been closely guarded on 

desktop and personal computers. However, there are no these same security grounds. The cards were first used by 

conventional Java implementations on microcontrollers, as go French banks as debit cards. In this application, before a 

would typically be used in a smart card. financial transaction based on the card is authorized, the card 

Microcontrollers differ from microprocessors in many user must demonstrate knowledge of a 4-digit personal 

ways. For example, a microprocessor typically has a central identification number (PIN) stored in the card in addition to 

processing unit that requires certain external components being in possession of the card. Any information that might 

(e.g., memory, input controls and output controls) to func- 65 contribute to discovering the PIN number on a lost or stolen 

tion properly. A typical microprocessor can access from a card was blocked from public distribution. In fact, since 

megabyte to a gigabyte of memory, and is capable of nobody could tell what information might be useful in this 
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regard, virtually all information about integrated circuit high level languages such as Java and Eiffel, using powerful 

cards was withheld. mainstream program development tools. New applications 

Due to the concern for security, applications written for «* V&*& prototyped and downloaded to a smart card 

integrated circuit cards have unique properties. Forexample, m ■ matter ° f houB wllboul f"*"* 10 masks - Embed : 

each application typically is identified with a particular 5 f ed systems _ usrng mtcrocontrollers can also gain many of 

rr . , . JL i- * - n **. these advantages for downloading new applications, high 

owner or idenUty. Because app rations typically are written program development, and rapid prototyping by mak- 

in a low-level programming language, such as assembly . mV enUon. 

lang^ge, the applications are written .for a particular type of Implem eatatioDS of the invention may include one or 
microcoria ^ mor / of me foUowing . The high level programming lan- 
languages, unauthorized applications may access data on the w rf ^ applicatioD may have a class file format 
integrated circuit card. Programs written for an integrated and may havc a Java programming language format. The 
circuit card are identified with a particular identity so that if pr0 cessor may be a microcontroller. At least a portion of the 
two identities want to perform the same programming memory may be located in the processor, 
function there must be two copies of some portions of the The application may have been processed from a second 
application on the microcontroller of the integrated circuit 15 application that has a string of characters, and the string of 
card. characters may be represented in the first application by an 

Integrated circuit card systems have historically been identifier (e.g., an integer), 

closed systems. An integrated circuit card contained a dedi- The processor may be also configured to receive a request 

cated application that was handcrafted to work with a from a requester (e.g., a processor or a terminal) to access an 

specific terminal application. Security checking when an 20 element (e.g., an application stored in the memory, data 

integrated circuit card was used consisted primarily of stored in the memory or the communicator) of the card, after 

making sure that the card application and the terminal receipt of the request, interact with the requester to authen- 

application were a matched pair and that the data on the card ticatc an identity of the requester, and based on the identity, 

was valid selectively grant access to the element. 

. , c . , . j . .25 The memory may also store an access control list for the 

As the popularity of integrated circuit cards grew, it elemenl ^ ^ ^ aQ indicatioQ of 

became clear that integrated circuit card users would be Qf accesg tQ ^ ^ l0 ^ ideQti and base(J Qn tfae 

averse to carrying a different integrated circuit card for each acc£SS conlrol ^ me processor selectively grants specific 

integrated circuit card application. Therefore, multiple coop- ty?es of access (e g ^ reading data> dala> appending 

erating applications began to be provided on single provider 3Q data> creatmg data) deleting data or executing an application) 

integrated circuit cards. Thus, for example, an automated to mc re q U ester. 

teller machine (ATM) access card and a debit card may application may be one of a several applications 
coexist on a single integrated circuit card platform. slored m mc memory. The processor may be further con- 
Nevertheless, this was still a closed system since all the figured to receive a request from a requester to access one of 
applications in the terminal and the card were built by one 35 the plurality of applications; after receipt of the request, 
provider having explicit knowledge of the other providers. determine whether said one of the plurality of applications 
The paucity of information about integrated circuit complies with a predetermined set of rules; and based on the 
cards — particularly information about how to communicate determination, selectively grant access to the requester to 
with them and how to program them — has impeded the said one of the plurality of applications. The predetermined 
general application of the integrated circuit card. However, ^ rules provide a guide for determining whether said one of the 
the advent of public digital networking (e.g., the Internet and plurality of applications accesses a predetermined region of 
the World Wide Web) has opened new domains of applica- the memory. The processor may be further configured to 
tion for integrated circuit cards. In particular, this has lead to authenticate an identity of the requester and grant access to 
a need to load new applications on the card that do not have said one of the plurality of applications based on the identity, 
explicit knowledge of the other providers, but without the 45 The processor may be also configured to interact with the 
possibility of compromising the security of the card. terminal via the communicator to authenticate an identity; 
However, typically, this is not practical with conventional determine if the identity has been authenticated; and based 
cards that are programmed using low level languages. on the determination, selectively allow communication 

m _ , between the terminal and the integrated circuit card. 

SUMMARY OF THE INVENTION 5Q ^ commuQicator ^ te termma i may communicale 

In general, in one aspect, the invention features an inte- via communication channels. The processor may also be 

grated circuit card for use with a terminal. The integrated configured to assign one of the communication channels to 

circuit card includes a memory that stores an interpreter and the identity when the processor allows the communication 

an application that has a high level programming language between the terminal and the integrated circuit card. The 

format. A processor of the card is configured to use the 55 processor may also be configured to assign a session key to 

interpreter to interpret the application for execution and to the assigned communication channel and use the session key 

use a communicator of the card to communicate with the when the processor and the terminal communicate via the 

terminal. assigned communication channel. 

Among the advantages of the invention are one or more The terminal may have a card reader, and the communi- 
of the following. New applications may be downloaded to a 60 cator may include a contact for communicating with the card 
smart card without compromising the security of the smart reader. The terminal may have a wireless communication 
card. These applications may be provided by different com- device, and the communicator may include a wireless trans- 
panies loaded at different times using different terminals. ceiver for communicating with the wireless communication 
Security is not compromised since the applications are device. The terminal may have a wireless communication 
protected against unauthorized access of any application 65 device, and the communicator may include a wireless trans- 
code or data by the security features provided by the Java mitter for communicating with the wireless communication 
virtual machine. Smart card applications can be created in device. 
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In genera], in another aspect, the invention features a municate with the terminal and a memory that stores a first 

method for use with an integrated circuit card and a terminal. application that has been processed from a second applica- 

The method includes storing an interpreter and at least one tion having a string of characters. The string of characters 

application having a high level programming language for- are represented in the first application by an identifier. The 

mat in a memory of the integrated circuit card. A processor 5 integrated circuit card includes a processor that is coupled to 

of the integrated circuit card uses the interpreter to interpret the memory. The processor is configured to use the inter- 

the at least one application for execution, and the processor preter to interpret the first application for execution and to 

uses a communicator of the card when communicating use the communicator to communicate with the terminal, 

between the processor and the terminal. i Q general, in another aspect, the invention features a 

In general, in another aspect, the invention features a 10 method for use with an integrated circuit card and a terminal, 

smart card. The smart card includes a memory that stores a The method includes processing a second application to 

Java interpreter and a processor that is configured to use the create a first application. The second application has a string 

interpreter to interpret a Java application for execution. of characters. The string of characters is represented by an 

In general, in another aspect, the invention features a identifier in the second application. An interpreter and the 

microcontroller that has a semiconductor substrate and a 15 first application are stored in a memory of the integrated 

memory located in the substrate. A programming language circuit card. A processor uses an interpreter to interpret the 

interpreter is stored in the memory and is configured to first application for execution. 

implement security checks. A central processing unit is In general, in another aspect, the invention features a 

located in the substrate and is coupled to the memory. microcontroller that includes a memory which stores an 

Implementations of the invention may include one or 20 application and an interpreter. The application has a class file 

more of the following. The interpreter may be a Java byte format. A processor of the microcontroller is coupled to the 

code interpreter. The security checks may include establish- memory and is configured to use the interpreter to interpret 

ing firewalls and may include enforcing a sandbox security the application for execution. 

model. ^ In implementations of the invention, the microcontroller 

In general, in another aspect, the invention features a may also include a communicator that is configured to 

smart card that has a programming language interpreter communicate with a terminal. 

stored in a memory of the card. The interpreter is configured In general, in another aspect, the invention features a 

to implement security check. A central processing unit of the method for use with an integrated circuit card. The method 

card is coupled to the memory. 3Q includes storing a first application in a memory of the 

In general, in another aspect, the invention features an integrated circuit card, storing a second application in the 

integrated circuit card that is used with a terminal. The card memory of the integrated circuit card, and creating a firewall 

includes a communicator and a memory that stores an that isolates the first and second applications so that the 

interpreter and first instructions of a first application. The second application cannot access either the first application 

first instructions have been converted from second instruc- 35 or data associated with the first application, 

tions of a second application. The integrated circuit card In general, in another aspect, the invention features an 

includes a processor that is coupled to the memory and is integrated circuit card for use with a terminal. The integrated 

configured to use the interpreter to execute the first instruc- circuit card includes a communicator that is configured to 

tions and to communicate with the terminal via the com- communicate with the terminal, a memory and a processor, 

municator. ^ The memory stores applications, and each application has a 

Implementations of the invention may include one or high level programming language format. The memory also 

more of the following. The first and/or second applications stores an interpreter. The processor is coupled to the memory 

may have class file format(s). The first and/or second and is configured to: a.) use the interpreter to interpret the 

applications may include byte codes, such as Java byte applications for execution, b.) use the interpreter to create a 

codes. The first instructions may be generalized or renum- 45 firewall to isolate the applications from each other, and c.) 

bered versions of the second instructions. The second use the communicator to communicate with the terminal, 

instructions may include constant references, and the first Other advantages and features will become apparent from 

instructions may include constants that replace the constant the following description and from the claims, 
references of the second instructions. The second instruc- 

tions may include references, and the references may shift 50 B RIEF DESCRIPTION OF THE DRAWING 

location during the conversion of the second instructions to pr<3 1 ^ a 0 i oc k diagram of an integrated card system, 

the first instructions. The first instructions may be relinked FIG. 2 is a flow diagram illustrating the preparation of 

to the references after the shifting. The first instructions may Java lications to te downloaded lo an integrated circuit 

include byte codes for a first type of virtual machine, and the caf( j 

second instructions may include byte codes for a second 55 _* - . ., tJ . r ,u *i a a * a 

c 1 u- -n. c *« • A-tT „ * c — »u FIG. 3 is a block diagram of the files used and generated 

type of virtual machme. The first type is different from the t . , . C1 ^ 

' , , by the card class file converter, 

second type. J _ 

In general, in another aspect, the invention features a c mG - 4 15 a block diagram illustrating the transformation 

method for use with an integrated circuit card. The method of a PP hcatl0n class mc ( s ) int ° a card class file - 

includes converting second instructions of a second appli- 6 0 FIG * 5 15 a flow dia e ram illustrating the working of the 

cation to first instructions of a first application; storing the c l ass fi* e converter. 

first instructions in a memory of the integrated circuit card; FIG. 6 is a flow diagram illustrating the modification of 

and using an interpreter of the integrated circuit card to the byte codes. 

execute the first instructions. FIG. 7 is a block diagram illustrating the transformation 

In general, in another aspect, the invention features an 65 of specific byte codes into general byte codes, 

integrated circuit for use with a terminal. The integrated FIG. 8 is a block diagram illustrating the replacement of 

circuit card has a communicator that is configured to com- constant references with constants. 
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FIG. 9 is a block diagram illustrating the replacement of communicator 126. The terminal communicator 126 is a 

references with their updated values. communications device capable of establishing a commu* 

FIG. 10 is a block diagram illustrating renumbering of nications channel between the integrated circuit card 10 and 

original byte codes. me terminal 14. Some communication options include con- 

FIG. 11 is a block diagram illustrating translation of 5 Ucl CKd read f ■ *? re,e » communications via radio fre- 

original byte codes for a different virtual machine architec- VW, 01 techniques, sena communication 

protocols, packet communication protocols, ISO 7816 com- 

„^ , munication protocol, to name a few. 

FIG. 12 is a block diagram illustrating loading apphca- _ . , „ . . 

j The terminal 14 can also interact with applications run- 

Uons into an in te era ted circuit card. . . , , . <u v ; Ja T FF 

„„ ,7 . . 10 mng in the integrated circuit card 10. In some cases, different 

FIG. 13 is a block diagram illustrating executing appli- ^ ^ fof mcsc ^ For cxam lc , onc 

cations in an mtegrated circuit card. kind of terminal may be used to prepare applications, 

FIG. 14 is a schematic diagram illustrating memory different terminals could be used to download the 

organization for ROM, RAM and EEPROM. applications, and yet other terminals could be used to run the 

FIG. 15 is a flow diagram illustrating the overall archi- 15 various applications. Terminals can be automated teller 

tecture of the Card Java virtual machine, machines (ATMs), point-of-sale terminals, door security 

FIG. 16 is a flow diagram illustrating method execution in systems, toll payment systems, access control systems, or 

the Card Java virtual machine with the security checks. any other system that communicates with an integrated 

FIG. 17 is a flow diagram illustrating byte code execution circuit card or microcontroller, 

in the Card Java virtual machine. The integrated circuit card 10 contains a card Java virtual 

FIG. 18 is a flow diagram illustrating method execution in machine £ Ca ' d J ^ 16 > ™ hich } s ™* |° inter P ret ^ 

the Card Java virtual machine without the security checks. catlons are ™ the 10 - 

FIG. 19 is a block diagram illustrating the association T Referrin S tc ^ G fl , 2 ' * c Java ^^ on ™ 

, .. .. j - i .... Java source code files Ajava 20a, B.iava 206, and Cjava 

between card apphcations and identities. 25 - A ~ , n ? J , , M , J . 

20c. Inese source code tiles are prepared and compiled in a 

FIG. 20 is a block diagram illustrating the access rights of Java app u cat i OD development environment 22. When the 

a specific running application. Java application 20 is compiled by the development envi- 

FIG. 21 is a perspective view of a microcontroller on a ronment 22, application class files 24 are produced, with 

smart card. ^ these class files A.class 24a, B.class 246, and C.class 24c 

FIG. 22 is a perspective view of a microcontroller on a corresponding to their respective class Java source code 20a, 

telephone. 206, and 20c. The application class files 24 follow the 

FIG. 23 is a perspective view of a microcontroller on a standard class file format as documented in chapter 4 of the 

key ring ^ ava v""* 11 *! machine specification by Tim Lindholm and 

... „. . c M , „ „ Frank Yellin, "The Java Virtual Machine Specification," 

FIG. 24 is a perspective view of a microcontroller on a 35 .... „, \ ~ .. . . ~ A 

r Addison -Wesley, 1996. These application class tiles 24 are 

nn ^' fed into the card class file converter 26, which consolidates 

FIG. 25 is a perspective view of a microcontroller on a and compresses the files, producing a single card class file 

circuit card of an automobile. 2 7. The card class file 27 is loaded to the integrated circuit 

DETAILED DESCRIPTION OF THE « cri 10 ^ . wiweiittad ^ lo^r 28. 

PREFERRED EMBODIMENTS , ^""W t0 3 > l * e class file f er * 18 » 

class file postprocessor that processes a set of class files 24 

Referring to FIG. 1, an integrated circuit card 10 (e.g., a that are encoded in the standard Java class file format, 

smart card) is constructed to provide a high level, Java- optionally using a string to ID input map file 30 to produce 

based, multiple application programming and execution 45 a Java card class file 27 in a card class file format. One such 

environment. The integrated circuit card 10 has a commu- card class file format is described in Appendix A which is 

nicator 12a that is configured to communicate with a ter- hereby incorporated by reference. In addition, in some 

minal communicator 126 of a terminal 14. In some embodiments, the card class file converter 26 produces a 

embodiments, the integrated circuit card 10 is a smart card string to ID output map file 32 that is used as input for a 

with an 8 bit microcontroller, 512 bytes of RAM, 4K bytes 5Q subsequent execution of the card class file converter, 

of EEPROM, and 20K of ROM; the terminal communicator \ a some embodiments, in order for the string to ID 

126 is a conventional contact smart card reader; and the mapping to be consistent with a previously generated card 

terminal 14 is a conventional personal computer running the fii c ( m the case where multiple class files reference the 

Windows NT operating system supporting the personal same strings), the card class file converter 26 can accept 

computer smart card (PC/SQ standard and providing Java 55 previously defined string to ID mappings from a string to ID 

development support. input map file 30. In the absence of such a file, the IDs are 

In some embodiments, the microcontroller, memory and generated by the card class file converter 26. Appendix B, 

communicator are embedded in a plastic card that has which is hereby incorporated by reference, describes one 

substantially the same dimensions as a typical credit card. In possible way of implementing and producing the string to ID 

other embodiments, the microcontroller, memory and com- $0 input map file 30 and string to ID output map file 32 and 

municator are mounted within bases other than a plastic illustrates this mapping via an example, 

card, such as jewelry (e.g., watches, rings or bracelets), Referring to FIG. 4, a typical application class file 24a 

automotive equipment, telecommunication equipment (e.g., includes class file information 41; a class constant pool 42; 

subscriber identity module (SIM) cards), security devices class, fields created, interfaces referenced, and method infor- 

(e.g., cryptographic modules) and appliances. 65 ma tion 43; and various attribute information 44, as detailed 

The terminal 14 prepares and downloads Java apphca- in aforementioned Java Virtual Machine Specification. Note 

tioos to the integrated circuit card 10 using the terminal that much of the attribute information 44 is not needed for 
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this embodiment and is eliminated 45 by the card class file SourceFile, Constant Value, Exceptions, LineNumberTable, 

converter 26. Eliminated attributes include SourceFile, and LocalVariableTable may be safely discarded 45. The 

ConstantValue, Exceptions, LineNumberTable, only attribute that is retained is the Code attribute. The Code 

LocalVariableTable, and any optional vendor attributes. The attribute contains the byte codes that correspond to the 

typical card class file 27 as described in Appendix A is 5 methods in the Java class file 24a. 

derived from the appUcation class files 24 in the following Modifyin ^ byte ^ 54 invoWcs examining the 

manner. The card class file information 46 is derived from _ . ./, . ■ c '■ lt c u .u j • ,u 1 

. 1 ci • r At c ■■ i- .• Code attribute information 44 for each method in the class 

the aggregate class file information 41 of all application ... , j r u . _j .u . t . 

. *T, ... . . , _, rr . . file, and modifying the operands of byte codes that refer to 

class files 24a, 24b, and 24c. The card class file constant . . ■ , , >, . . , A ~ . a ,u 

■ mt- j • j c .1. .1 . • • a-> entries in the Java class file constant pool 42 to reflect the 

pool 47 is derived from the aggregate class constant pool 42 , n .. ,, , , C1 . , , An . _ 

v . „ ... , ., , . b ,., . , . _r . i° entnes m the card class file constant pool 47. In some 

of all application class files 24a, 246, and 24c. The card ... . . . . , . V.. . . ., , 

„ , ^ ...... f j j ... ■ , embodiments, the byte codes are also modified, as described 

class, fields created, interfaces referenced, and method infor- 

mation 48 is derived from the aggregate class, fields created, 

interfaces referenced, and method information 43 of all Modifying the byte codes 54 involves five passes (with 

application class files 24fl, 24i>, and 24c. The card attribute 15 ^ °P tional P 35565 ) 35 described by the flowchart in FIG. 6. 

information 49 in this embodiment is derived from only the ori S> nal b y te °° des 60 are found in tne Code attribute 44 

code attribute of the aggregate attribute information 44 of all °f the Java class fiIe 240 processed. The first pass 61 

application class files 24a, 246, and 24c. records a11 tne i um P s and & eir destinations in the original 

To avoid dynamic linking in the card, all the information ^ ^ Durin 8 later byte code translation some angle 

that is distributed across several Java class files 24a, 246, 20 W» °° de m ^ be to dual „ 0t «% le * y **\l • 

and 24c that form the application 24, are coalesced into one Ulu f rat f a ° exam P le Z*?™^^ ILOAD_0 .s 

card class file 27 by the process shown ,n the flowchart in ff P lac ^. wUh ! W0 b £ 8 '*** ^ I "^T ? 

FIG. 5. The first class file to be processed is selected 51a. ™» a ' hls » done ! ^.^V^T?? ^ 

The constant pool 42 is compacted 516 in the following ™ nt °f a »y jump desdnahons which are affected. Therefore, 

manner. All objects, classes, fields, methods referenced in a 2S «*f°™ ll <** are me original byte 

Java class file 24a are identified by using strings in the «*» » « m ^ f ° r ^ J um P ^te codes and a note 

constant pool 42 of the class file 24a. The card class file made ° f ,heir position and current destination. The program 

converter^ compacts the constant pool 42 found in the Java f 0 * tog™ 1 " » ? shows how ' hs f 

class file 24* into an optimized version. This compaction is J um P s m recorded - A PP eodlx 15 hereb y ^rporated by 

achieved by mapping all the strings found in the class file 30 reterence * 

constant pool 42 into integers (the size of which is micro- 0nce the J" 111 ! 55 are recorded, if the optional byte code 

controller architecture dependent). These integers are also translation is not being performed 62, the card class file 

referred to as IDs. Each ID uniquely identifies a particular converter 26 may proceed to the third pass 64. 

object, class, field or method in the application 20. Otherwise, the card class file converter converts specific 

Therefore, the card class file converter 26 replaces the 35 byte codes into generic byte codes. Typically, the translated 

strings in the Java class file constant pool 42 with its byte codes are not interpreted in the Card JVM 16 but are 

corresponding unique ID. Appendix B shows an example supported by converting the byte codes into equivalent byte 

application HelloSmartCard java, with a table below illus- codes that can be interpreted by the Card JVM 16 (see FIG. 

trating the IDs corresponding to the strings found in the 7). The byte codes 70 may be replaced with another seman- 

constant pool of the class file for this application. The IDs 40 tically equivalent but different byte codes 72. This generally 

used for this example are 16-bit unsigned integers, entails the translation of short single specific byte codes such 

Next, the card class file converter 26 checks for unsup- as ILOAD__0 into their more general versions. For example, 

ported features 51c in the Code attribute of the input Java ILOAD_0 may be replaced by byte code ILOAD with an 

class file 24a. The Card JVM 16 only supports a subset of argument 0. This translation is done to reduce the number of 

the full Java byte codes as described in Appendix C, which 45 byte codes translated by the Card JVM 16, consequendy 

is hereby incorporated by reference. Hence, the card class reducing the complexity and code space requirements for the 

file converter 26 checks for unsupported byte codes in the Card JVM 16. The program code fragment marked "C" in 

Code attribute of the Java class file 24a. If any unsupported Appendix D shows how these translations are made. Note 

byte codes are found 52, the card class file converter flags an that such translations increase the size of the resulting byte 

error and stops conversion 53. The program code fragment 50 c °d c force the re-computation of any jumps which are 

marked "A" in APPENDIX D shows how these spurious affected. 

byte codes are apprehended. Another level of checking can In the third pass 64, the card class file converter rebuilds 

be performed by requiring the standard Java development constant references via elimination of the strings used to 

environment 22 to compile the application 20 with a *-g* denote these constants. FIG. 8 shows an example wherein 

flag. Based on the aforementioned Java virtual machine 55 the byte code LDC 80 referring to constant "18" found via 

specification, this option requires the Java compiler to place an index in the Java class file 24a constant pool 42 may be 

information about the variables used in a Java application 20 translated into BIPUSH byte code 82. In this pass the card 

in the LocalVariableTable attribute of the class file 24a. The class file converter 26 modifies the operands to all the byte 

card class file converter 26 uses this information to check if codes that refer to entries in the Java class file constant pool 

the Java class file 24a references data types not supported by 60 42 to reflect their new location in the card class file constant 

the Java card. pool 47. FIG. 9 shows an example wherein the argument to 

Next, the card class file converter 26 discards all the a byte code, INVOKESTATIC 90, refers to an entry in the 

unnecessary parts 51c of the Java class file 24a not required Java class file constant pool 42 that is modified to reflect the 

for interpretation. A Java class file 24a stores information new location of that entry in the card class file constant pool 

pertaining to the byte codes in the class file in the Attributes 65 47. The modified operand 94 shows this transformation. The 

section 44 of the Java class file. Attributes that are not program code fragment marked "D" in Appendix D shows 

required for interpretation by the card JVM 16, such as how these modifications are made. 
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Ooce the constant references are relinked, if the optional aiing system 122. In the preferred embodiment, the boot- 
byte code modification is not being performed, the card class strap loader is written in Java, and the integrated circuit card 
file converter may proceed to the fifth and final pass 67. 10 includes a Java virtual machine to run this application. A 
Otherwise, the card class file converter modifies the Java implementation of (he loadmg and execution control 
original byte codes into a different set of byte codes sup- s » grated m Append* E wtuch is hereby locorpo- 

ported by the particular Card JVM 16 bekg used. One ra,e ? bv r ' feren ?- V* "J °°i ^ 

v v<"" ' , " . , * ' "„ receives the card class file 26 and produces a Java card 

potemtal modification renumbers me ongmal byte codes 60 application ^ stored in the card file system 126 in the 

into Card JVM 16 byte codes (sec FIG. 10). This renum- rafpROM of the integrated circuit card 10. Multiple Java 

berag causes toe byte codes 100 in the original byte codes card applications 126x , I26y, and 12& can be stored in a 

60 to be modified into a renumbered byte ^codes 102. Byte 10 ^ ^ ^ ^ ^ ^ execution 

code ILOAD recognized by value 21 may be renumbered to m commands whereby the terminal 14 

be recognized by value 50. This modification may be done cm ^ whfch Java ^ ^ catioa to ^mediately, 

for optimizing the type tests (also known in prior art as Pass or the nexl card ^ 

3 d ^JL?. tbC A 0ud i V ?J V 6 ' ^ Pr ° g 7 Un ^f. 63 ^,? 01 1S Referring to FIG. 13, upon receiving a reset or an execu- 

marked E m ^PPendix : D shows an unplementaUon of this « ^ ^ ^ fo ^ 

embodunent. This modification may be done ; morder o ^ Jaya Machine ^ ^ u 

reduce the program space rcqwred by the Card JVM 16 to a( a melho V d (for example> mai ^ of 

interpret the byte code E«entudly this modification ^ ^ ^ Javg Card Ucalion 12fc 

regroups the byte codes into Card J VM 16 byte codes so that ^ Card M jdes ^ Jaya ^ 12fa 

byte codes with similar operands, results are grouped 20 ^ 

together, and there are no gaps between Card JVM 16 byte ... lt.-J * u m renn^u ' fi1 „ 

j it .i_ o j , cc ■ .i L i provides capabilities such as I/O, EEPROM support, file 

codes. This allows the Card JVM 16 to efficiently check r r . , ... . ^ . 

^T*y„„Ti^ t j , J ■ j 4 * . systems, access control, and other system functions using 

Card JVM 16 byte codes and validate types as it executes. . . , ... ... . , . . A j- t- u- u ■ 

J native Java methods as illustrated in Appendix F which is 

In some embodiments, the card class file converter modi- hereby i DCOrp orated by reference, 
fies the original byte codes 60 into a different set of byte ^ Java cafd licatiorJ 1262 communicates 
codes designed for a different virtual machine archUecture ^ an appropriate app Ucation in the terminal 14 using the 
as shown m FIG. 11. The Java byte code ILOAD 112 communicator Ua t0 ntfbtoh a communication channel to 
intended for use on a word stack 114 may be replaced by ±c tcrminal R Data from ^ X2a t0 thc 
Card JVM 16 byte code ILOAD_B 116 to be used on a byte terminaI 14 passcs througD a communicator driver 132 in the 
stack 118. An element m a word stack 114 requires allocat- tenninalf which is specifically written to handle the com- 
ing 4 bytes of stack space, whereas an element id the byte munications protoC ol used by the communicator 12a. The 
stack 118 requires only one byte of stack space. Although datfl thcQ s tQ M intcgrated circuit card drivcr 134> 
this option may provide an increase in execution speed, it which is spccifically bitten to address the capabilities of the 
risks losing the security features available in the original ^ parlicular integrated circuit card 10 being used, and provides 
byte codes. bigb level software services to the terminal application 136. 

Since the previous steps 63, 64 or 66 may have changed j n me preferred embodiment, this driver would be appro- 

the size of the byte codes 60 the card class file converter 26 priatc PC /SC Smartcard Service Provider (SSP) software, 

has to relink 67 any jumps which have been effected. Since The data then passes to the terminal application 136, which 

the jumps were recorded in the first step 61 of the card class 4Q must handlc mc capabilities provided by the particular card 

file converter 26, this adjustment is carried out by fixing the application 126z being run. In this manner, commands and 

jump destinations to their appropriate values. The program responses pass back and forth between the terminal appli- 

code fragment marked "F' in Appendix D shows how these cation 136 and mc selected card application 126z. The 

jumps are fixed. terminal application interacts with the user, receiving com- 

The card class file converter now has modified byte codes 45 mands from the user, some of which are passed to the 

68 that is equivalent to the original byte codes 60 ready for selected Java card application 126z, and receiving responses 

loading. The translation from the Java class file 24a to the from the Java card application 126z, which are processed 

card class file 27 is now complete. and passed back to the user. 

Referring back to FIG. 5, if more class files 24 remain to Referring to FIG. 14, the Card JVM 16 is an interpreter 

be processed 55 the previous steps 51a, 516, 51c, 52 and 54 50 that interprets a card application 126*. The memory 

are repeated for each remaining class file. Thc card class file resources in the microcontroller that impact the Card JVM 

converter 26 gathers 56 the maps and modified byte codes 16 are the Card ROM 140, Card RAM 141 and the Card 

for the classes 24 that have been processed, places them as EEPROM 142. The Card ROM 140 is used to store the Card 

an aggregate and generates 57 a card class file 27. If JVM 16 and the card operating system 122. Card ROM 140 

required, the card class file converter 26 generates a string 55 may also be used to store fixed card applications 140ft and 

to ID output map file 32, that contains a list of all the new class libraries 1406. Loadable applications 141a, 1416 and 

IDs allocated for the strings encountered in the constant pool libraries 141c may also be stored in Card RAM 141. The 

42 of the Java class files 24 during the translation. Card JVM 16 interprets a card application 141a, 1416, or 

Referring to FIG. 12, the card loader 28 within the 140a. The Card JVM 16 uses the Card RAM to store the VM 

terminal 14 sends a card class file to the loading and 60 stack 144a and system state variables 1446. The Card JVM 

execution control 120 within the integrated circuit card 10 16 keeps track of the operations performed via the VM stack 

using standard ISO 7816 commands. The loading and execu- 144a. The objects created by the Card JVM 16 are either on 

tion control 120 with a card operating system 122, which the RAM heap 144c, in the EEPROM heap 146a, or in the 

provides the necessary system resources, including support file system 147, 

for a card file system 124, which can be used to store several 65 All of the heap manipulated by the Card JVM 16 may be 

card applications 126. Many conventional card loaders are stored in the Card RAM 141 as a RAM Heap 144c, or it may 

written in low level languages, supported by the card oper- be distributed across to the Card EEPROM 142 as a 
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EEPROM Heap 146a. Card RAM 141 is also used for method code (subroutine written in the microcontroller's 

recording the state of the system stack 148 that is used by native processor code). In this case, the Card JVM 16 

routines written in the native code of the microcontroller. prepares for an efficient call 163 and return to the native code 

The Card JVM 16 uses the Card EEPROM 142 to store subroutine. The parameters to the native method may be 

application data either in the EEPROM heap 146a or in the 5 passed on the VM stack 144a or via the System stack 148. 

file system 147. Application data stored in a file may be The appropriate security checks are made and the native 

manipulated via an interface to the card operating system method subroutine is called. On return, the result (if any) of 

122. This interface is provided by a class library 1406 stored the native method subroutine is placed on the VM stack 

in Card ROM 140, by a loadable class library 141c stored in 144a so that it may be accessed by the next byte code to be 

Card EEPROM 142. One such interface is described in 10 executed. 

Appendix F. Applications and data in the card are isolated by Th c dispatch loop 164 of the Card JVM 16 is then entered, 

a firewall mechanism 149. Th c byte code dispatch loop is responsible for preparing, 

To cope with the limited resources available on executing, and retiring each byte code. The loop terminates 

microcontrollers, the Card JVM 16 implements a strict when it finishes interpreting the byte codes in the method 

subset of the Java programming language. Consequently, a 15 160, or when the Card JVM 16 encounters a resource 

Java application 20 compiles into a class file that contains a limitation or a security violation. 

strict subset of Java byte codes. This enables application if a previous byte code caused a branch to be taken 165 

programmers to program in this strict subset of Java and still the Card JVM prepares for the branch 165a. The next byte 

maintain compatibility with existing Java Virtual Machines. co d e jg retrieved 1656. In order to keep the cost of process- 

The semantics of the Java byte codes interpreted by the Card 20 fog each byte code down, as many common elements such 

JVM 16 are described in the aforementioned Java Virtual as t ne byte code arguments, length, type are extracted and 

Machine Specification. The subset of byte codes interpreted stored, 

by the Card JVM 16 can be found in Appendix C. The card Tq provide lhfi offered by the security model of 

class file converter 26 checks the Java application 20 to the programming language, byte codes in the class file must 

ensure use of only the features available in this subset and 25 ^ ^ determined to mis modeL These 

converts into a form that is understood and interpreted by the checks are typicaIly carried out m prior art by a program 

Card JVM 16. referred to as the byte code verifier, which operates in four 

In other embodiments, the Card JVM 16 is designed to passes as described in the Java Virtual Machine Specifica- 

interpret a different set or augmented set of byte codes 116. tion. To offer the run-time security that is guaranteed by the 

Although a different byte code set might lead to some byte code verifier, the Card JVM 16 must perform the checks 

performance improvements, departing from a strict Java that pertain to the Pass 3 and Pass 4 of the verifier. This 

subset may not be desirable from the point of view of checking can be bypassed by the Card JVM 16 if it can be 

security that is present in the original Java byte codes or guaranteed (which is almost impossible to do) that the byte 

compatibility with mainstream Java development tools. ^ coc j e s 60 interpreted by the Card JVM 16 are secure. At the 

All Card JVM 16 applications 126 have a defined entry minimum, code security can be maintained as long as object 

point denoted by a class and a method in the class. This entry references cannot be faked and the VM stack 144a and local 

point is mapped in the string to ID input map 30 and variable bounds are observed. This requires checking the 

assigned by the card class file converter 26. Classes, meth- state of the VM stack 144a with respect to the byte code 

ods and fields within a Java application 20 are assigned IDs being executed. 

by the card class file converter 26. For example, the ID j Q enforce the security model of the programming 

corresponding to the main application class may be defined language, a 256-byte table is created as shown in Appendix 

as F001 and the ID corresponding to its main method, such q wn j cn is hereby incorporated by reference. This table is 

as "main()V" could be defined as F002. indexed by the byte code number. This table contains the 

The overall execution architecture of the Card JVM is 45 type and length information associated with the indexing 

described by the flowchart in FIG. 15. Execution of the Card byte code. It is encoded with the first 5 bits representing 

JVM 16 begins at the execution control 120, which chooses type, and the last 3 bits representing length. The type and 

a card application 126z to execute. It proceeds by finding length of the byte code is indexed directly from the table by 

and assigning an entry point 152 (a method) in this card the byte code number. This type and length is then used for 

application for the Card JVM 16 to interpret. The Card JVM 50 checking as shown in Appendix H which is hereby incor- 

16 interprets the method 153. If the interpretation proceeds porated by reference. In Appendix H, the checking process 

successfully 154, the Card JVM 16 reports success 155 begins by decoding the length and type from the table in 

returning control back to the execution control 120. If in the Appendix G which is hereby incorporated by reference. The 

course of interpretation 153 the Card JVM 16 encounters an length is used to increment the program counter. The type is 

unhandled error or exception (typically a resource limitation 55 used first for pre-cxecution checking, to insure that the data 

or a security violation), the Card JVM 16 stops 156 and types on the VM stack 144a are correct for the byte code that 

reports the appropriate error to the terminal 14. is about to be executed. The 256 bytes of ROM for table 

An essential part of the Card JVM 16 is a subroutine that storage allows the original Java byte codes to be run in the 

handles the execution of the byte codes. This subroutine is Card JVM 16 and minimizes the changes required to the 

described by the flowchart in FIG. 16. Given a method 160 60 ^ ava ^ c lo DC loaded in the card. Additional Java byte 

it executes the byte codes in this method. The subroutine codes can be easily supported since it is relatively easy to 

starts by preparing for the parameters of this method 161. update the appropriate table entries. 

This involves setting the VM stack 144a pointer, VM stack i n other embodiments, as shown in FIG. 10, the Java byte 

144a frame limits, and setting the program counter to the codes in the method are renumbered in such a manner that 

first byte code of the method. 65 the byte code type and length information stored in the table 

Next, the method flags are checked 162. If the method is in Appendix H is implicit in the reordering. Appendix H is 

flagged native, then the method is actually a call to native hereby incorporated by reference. Consequently, the checks 
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that must be performed on the state of the VM stack 144a 
and the byte code being processed does not have to involve 
a table look up. The checks can be performed by set of 
simple comparisons as shown in Appendix I which is hereby 
incorporated by reference. This embodiment is preferable 
when ROM space is at a premium, since it eliminates a 
256-byte table. However adding new byte codes to the set of 
supported byte codes has to be carefully thought out since 
the new byte codes have to fit in the implicit numbering 
scheme of the supported byte codes. 

In another embodiment, the Card JVM 16 chooses not to 
perform any security checks in favor of Card JVM 16 
execution speed. This is illustrated in the flowchart in FIG. 
18. The flow chart in FIG. 18 is the same as that of FIG. 16 
with the security checks removed. This option is not desir- 
able from the point of view of security, unless it can be 
guaranteed that the byte codes are secure. 

The Card JVM 16 may enforce other security checks as 
well. If the byte code may reference a local variable, the 
Card JVM 16 checks if this reference is valid, throwing an 
error if it is not. If the reference is valid, the Card JVM 16 
stores the type of the local variable for future checking. The 
VM stack 144a pointer is checked to see if it is still in a valid 
range. If not an exception is thrown. The byte code number 
is checked. If it is not supported, an exception is thrown. 

Finally, the byte code itself is dispatched 165a\ The byte 
codes translated by the Card JVM 16 are listed in Appendix 
C. The semantics of the byte codes are described in the 
aforementioned Java Virtual Machine Specification with 
regard to the state of the VM stack 144a before and after the 
dispatch of the byte code. Note also that some byte codes 
(the byte codes, INVOKESTATIC, INVOKESPECIAL, 
INVOKENONV1RTUAL and INVOKE VIRTUAL) may 
cause reentry into the Card JVM 16, requiring processing to 
begin at the entry of the subroutine 161. FIG. 17 shows the 
flowchart of the byte code execution routine. The routine is 
given a byte code 171 to execute. The Card JVM 16 executes 
172 the instructions required for the byte code. If in the 
course of executing the Card JVM 16 encounters a resource 
limitation 173, it returns an error 156. This error is returned 
to the terminal 16 by the Card JVM 16. If the byte code 
executes successfully, it returns a success 175. 

After execution, the type of the result is used to set the 
VM stack 144a state correctly 165e, properly flagging the 
data types on the VM stack 144a. The byte code information 
gathered previously 165b from the byte code info table is 
used to set the state of the VM stack 144a in accordance with 
the byte code that just executed. 

In other embodiments, setting the output state of the VM 
stack 144a with respect to the byte code executed is sim- 
plified if the byte code is renumbered. This is shown in 
Appendix I which is hereby incorporated by reference. 

In yet another embodiment, the Card JVM 16 may bypass 
setting the output state of the VM stack 144a in favor of 
Card JVM 16 execution speed. This option is not desirable 
from the point of view of security, unless it can be guaran- 
teed that the byte codes are secure. 

After the byte code has been executed, the byte code is 
retired 165/. This involves popping arguments off the VM 
stack 144a. Once byte code processing is completed, the 
loop 164 is repeated for the next byte code for the method. 

Once the dispatch loop 164 terminates, the VM stack 
144a is emptied 166. This prevents any object references 
filtering down to other Card JVM 16 invocations and 



To isolate data and applications in the integrated circuit 
card 10 from each other, the integrated circuit card 10 relies 
on the firewall mechanism 149 provided by the Card JVM 
16. Because the Card JVM implements the standard pass 3 

5 and pass 4 verifier checks, it detects any attempt by an 
application to reference the data or code space used by 
another application, and flag a security error 156. For 
example, conventional low level applications can cast non- 
reference data types into references, thereby enabling access 

to to unauthorized memory space, and violating security. With 
this invention, such an attempt by a card application 126z to 
use a non-reference data type as a reference will trigger a 
security violation 156. In conventional Java, this protected 
application environment is referred to as the sandbox 

15 application-interpretation environment. 

However, these firewall facilities do not work indepen- 
dently. In fact, the facilities are overlapping and mutually 
reinforcing with conventional access control lists and 
encryption mechanisms shown in the following table: 
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Taken together, these facilities isolate both data and 
applications on the integrated circuit card 10 and ensure that 
each card application 126 can access only the authorized 
resources of the integrated circuit card 10. 

Referring to FIG. 19, card applications 126r, 126y, 126z 
can be endowed with specific privileges when the card 
applications 126 execute. These privileges determine, for 
example, which data files the card applications 126 can 
access and what operations the card applications 126 can 
perform on the file system 147. The privileges granted to the 
card applications 126 are normally set at the time that a 
particular card application 126z is started by the user, 
typically from the terminal 14. 

The integrated circuit card 10 uses cryptographic identi- 
fication verification methods to associate an identity 190 
(e.g., identities 190a, 1906 and 190c) and hence, a set of 
privileges to the execution of the card application 126. The 
association of the specific identity 190c to the card appli- 
cation L26z is made when the card application 126z begins 
execution, thus creating a specific running application 200, 
as shown in FIG. 20. The identity 190 is a unique legible text 
string reliably associated with an identity token. The identity 
token (e.g., a personal identification number (PIN) or a RSA 
private key) is an encryption key. 

Referring to FIG. 20, in order to run a specific card 
application 126z, the identity 190c of the card application 



126z must be authenticated. The identity 190c is authenti- 
breaking the Card JVM's 16 security. Termination 167 of the 65 cated by demonstrating knowledge of the identity token 
byte code dispatch loop 164 indicates that the Card JVM 16 associated with the identity 190c. Therefore, in order to run 
has completed executing the requested method. the card application 126z, an agent (e.g., a card holder or 
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another application wishing to run the application) must tion is accomplished by including in the identity authenti- 

show that it possesses or knows the application's identity- cation process the exchange of a one-time session key 209 

denning encryption key. between the a card application 126z and the terminal appli- 

One way to demonstrate possession of an encryption key cation 136. The key 209 is then used to encrypt subsequent 

is simply to expose the key itself. PIN verification is an 5 between the authenticating terminal application 136 

example of this form of authentication. Another way to and toe authenticated card application 126z. Given the 

demonstrate the possession of an encryption key without one-time session key 209, a rogue terminal application can 

actually exposing the key itself is to show the ability to neither "listen in" on an authenticated communication 

encrypt or decrypt plain text with the key. between the terminal 14 and the integrated circuit card 10, 

Thug, a specific rom^ 10 nor can the rogue terminal application "spoor the card 

circuit card 10 includes a card application 126* plus an j^ 11011 ml ° P"*" 1 ™* ™ a *°<>nzed operations on its 

authenticated identity 190c. No card application 126 can be c * *. , , 

run without both of these elements being in place. The card u ^"P 1 .™ of card/terminal traffic can be 

application 12fc defines data processing operations to be handled , euher b ? lh , e f ™* U } OI b V the 

performed, and the authenticated identity 190c determines 15 card apphcation .tself 126z In the former case, the commu- 

on what computational objects those operations may be mc f ,on t f. rmmal 14 « bem 8 

performed. For example, a specific application U6z can ^ t0 „ the WhcaUon, and message traffic arrives 

only access identity C's files 202 in the file system 147 *aypted m ite dala space of the application. In the latter 

associated with the specific identity 190c, and the specific card W>^™ ™* <° perform encrypuon 

card application 12fe cannot access other files 204 that are 20 »»d decryption o provide an extra layer of security smce the 

associated with identities other than the specific identity 'PP^™ «>»" "crypt data as soon as U was created and 

jp^, would decrypt data only when it was about to be used. 

' . . , . . Otherwise, the data would remain encrypted with the session 

The integrated circuit card 10 may take additional steps to ^ 

ensure appucation and data isolation. The integrated circuit u ^ " , he UcatioD flrewall includes ^ mutuaUy 

card 10 furnishes three software featoes sets: authenticated- teinforci software sels . Data fii es are protected by 

identity access control hs* a Java-based vutual machine; autheotic a,ed.identity access control lists. Application 

and one-time session encryption keys to protect data files, executioD spaces are protected by the Card JVM 16. Com- 

app .cation execution, and communication channels, respec- munication cbimeh ^ prolected ^ one .ti m e session 

Uvely^CoUecuvely.fo^ x encryption keys 209. 

provide the application data firewalls 149 for one embodi- emDodiments> me aboV e^escribed techniques are 

ment. The following discusses each software feature set and ^ ^ a microcontroll e r (such as the processor 12) may 

then shows bow the three sets work together to insure devices ( of m aWomobile e me) olher 

application and data isolauon on the integrated circuit card ^ aQ circui , cardi In thest ap pi icalioas> t he 

35 microcontroller provides a small platform (i.e., a central 

An access control list (ACL) is associated with every processing unit, and a memory, both of which are located on 

computational object (e.g., a data file or a communication a semiconductor substrate) for storing and executing high 

channel) on the integrated circuit card 10 that is be !evel programming languages. Most existing devices and 

protected, i.e., to which access is to be controlled. An entry new designs that utilize a microcontroller could use this 

on an ACL (for a particular computational object) is in a data w invention to provide the ability to program the microcon- 

format referred to as an e-tuple: trailer using a high level language, and application of this 

type: identity permissions invention to such devices is specifically included. 

The type field indicates the type of the following identity (in The term application includes any program, such as Java 

the identity field), e.g., a user (e.g., "John Smith"), or a applications, Java applets, Java aglets, Java servlets, Java 

group. Hie permissions field indicates a list of operations 45 commlets, Java components, and other non-Java programs 

(e.g., read, append and update) that can be performed by the that can result in class files as described below, 

identity on the computational object. Class files may have a source other than Java program 

As an example, for a data file that has the ACL entry: files. Several programming languages other than Java also 

USER: Acme Airlines: RAU, have compilers or assemblers for generating class files from 

any application whose identity is "AcmeAirlines'* can read 50 their respective source files. For example, the programming 

("R"), append ("A") and update ("U") the data file. In language Eiffel can be used to generate class files using 

addition, the ACL may be used selectively to permit the Pirmin Kalberer's "J-Eiffei", an Eiffel compiler with JVM 

creation and deletion of data files. Furthermore, the ACL byte code generation (web site: http://www.spin.ch/ 

may be used selectively to permit execution of an applica- -kalberer/jive/index.htm). An Ada 95 to Java byte code 

tion. 55 translator is described in the following reference 

Whenever a computational object is accessed by a run- (incorporated herein by reference): Taft, S. Tucker, "Pro- 

ning application 200, the access is intercepted by the Card gramming the Internet in Ada 95**, proceedings of Ada 

JVM 16 and passed to the card operating system 122, which Europe '96, 1996. Jasmin is a Java byte code assembler that 

determines if there is an ACL associated with the object. If can be used to generate class files, as described in the 

there is an associated ACL, then the identity 190t associated 60 following reference (incorporated herein by reference): 

with the running application 200 is matched on the ACL. If Meyer, Jon and Troy Downing, "Java Virtual Machine", 

the identity is not found or if the identity is not permitted for O'Reilly, 1997. Regardless of the source of the class files, 

the type of access that is being requested, then the access is the above description applies to languages other than Java to 

denied. Otherwise, the access is allowed to proceed. generate codes to be interpreted. 

Referring to FIG. 13, to prevent the potential problems 65 FIG. 21 shows an integrated circuit card, or smart card, 

due to the single data path between the integrated circuit which includes a microcontroller 210 that is mounted to a 

card 10 and the terminal 14, communication channel isola- plastic card 212. The plastic card 212 has approximately the 
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same form factor as a typical credit card. The communicator 2. The integrated circuit card of claim 1, wherein the high 

12a can use a contact pad 214 to establish a communication level programming language format comprises a class file 

channel, or the communicator 12a can use a wireless com- format. 

munication system. 3. The integrated circuit card of claim 1 wherein the 

In other embodiments, a microcontroller 210 is mounted 5 processor comprises a microcontroller, 
into a mobile or fixed telephone 220, effectively adding 4. The integrated circuit card of claim 1 wherein at least 
smart card capabilities to the telephone, as shown in FIG. 22. a porl i OD 0 f the memory is located in the processor. 
In these embodiments, the microcontroller 210 is mounted 5 Th e integrated circuit card of claim 1 wherein the high 
on a module (such as a Subscriber Identity Module (SIM)), level programming language format comprises a Java pre- 
fer insertion and removal from the telephone 220. 10 gra rnm i ng language format. 

In other embodiments, a microcontroller 210 is added to 6 ne integrated circuit card of claim 1, wherein 

a key ring 230 as shown in FIG. 23. This can be used to tbe application has processed from a second appli- 

secure access to an automobile that is equipped to recognize cation havin fl lurali of m elemeDtS) at least 

the identity associated with the microcontroller 210 on the one being a string of characters, and 

keyring . 15 v^erem in the first application the string of characters is 

Jewelry such as a watch or ring 240 can also house a , , .j t . c 0 

,1 a . & . . . replaced with an identifier. 

mioocontoUer 210 w an economic manner, as shown m ? ^ . ^ ^ ^ rf chim 6 whcrein ^ 

FIG. 24. Such embodiments typically use a wireless com- . 

r ... identifier comprises an integer, 

munition system for establishing a communication g circu ;f card of claim 1 ^ the 

channel, and are a convenient way to implement access 20 ^ ^ confi d , 0 . 

control with a minimum of hassle to the user. * c & , t , 

FIG. 25 illustrates a microcontroller 210 mounted in an receive a ^ uest from a re ^ uesler 10 access 40 eleraent of 

electrical subsystem 252 of an automobile 254. In this , e car . ' m , ... 

embodiment, the microcontroller is used for a variety of after recerot of to re 9 uest > mteract ^ me re ? uester t0 

purposes, such as to controlling access to the automobOe, 25 authenticate an identity of the requester; and 

(e.g. checking identity or sobriety before enabling the igni- based on the identity, selectively grant access to the 

tioo system of the automobile), paying tolls via wireless element. 

communication, or interfacing with a global positioning 9 - The integrated circuit card of claim 8, wherein the 

system (GPS) to track the location of the automobile, to requester comprises the processor. 

name a few. 30 10- The integrated circuit card of claim 8, wherein the 

While specific embodiments of the present invention have requester comprises the terminal, 

been described, various modifications and substitutions will U* The integrated circuit card of claim 8, wherein 

become apparent to one skilled in the art by this disclosure. the element comprises the application stored in the 

Such modifications and substitutions are within the scope of memory, and 

the present invention, and are intended to be covered by the 35 once access is allowed, the requester is configured to use 

appended claims. the application. 

What is claimed is: 12. The integrated circuit card of claim 8, wherein 

1. An integrated circuit card for use with a terminal, the element comprises another application stored in the 

comprising: memory. 

a communicator configured to communicate with the 40 13. The integrated circuit card of claim 8, wherein the 

terminal; element includes data stored in the memory, 

a memory storing: 14. The integrated circuit card of claim 8 wherein the 

an application derived from a program written in a high element comprises the communicator, 

level programming language format wherein the 15. The integrated circuit card of claim 8, wherein the 

application is derived from a program written in a 45 memory also stores an access control list for the element, the 

high level programming language format by first access control list furnishing an indication of types of access 

compiling the program into a compiled form and to be granted to the identity, the processor further configured 

then converting the compiled form into a converted to: 

form, the converting step including at least one step based on the access control list, selectively grant specific 

selected from a group consisting of 50 types of access to the requester. 

recording all jumps and their destinations in the 16. The integrated circuit card of claim 15 wherein the 

original byte codes; types of access include reading data, 

converting specific byte codes into equivalent 17. The integrated circuit card of claim 15 wherein the 

generic byte codes or vice-versa; types of access include writing data, 

modifying byte code operands from references using 55 18. The integrated circuit card of claim 15 wherein the 

identifying strings to references using unique types of access include appending data, 

identifiers; and 19. The integrated circuit card of claim 15 wherein the 

renumbering byte codes in a compiled format to types of access include creating data. 

equivalent byte codes in a formal suitable for 20. The integrated circuit card of claim 15 wherein the 

interpretation; and 60 types of access include deleting data, 

an interpreter operable to interpret such an application 21. The integrated circuit card of claim 15 wherein the 

derived from a program written in a high level types of access include executing an application, 

programming language format; and 22. The integrated circuit card of claim 1, wherein the 

a processor coupled to the memory, the processor con- application is one of a plurality of applications stored in the 

figured to use the interpreter to interpret the application 65 memory, the processor is further configured to: 

for execution and to use the communicator to commu- receive a request from a requester to access one of the 

nicate with the terminal. plurality of applications; 
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after receipt of the request, determine whether said one of renumbering byte codes in a compiled format to 

the plurality of applications complies with a predeter- equivalent byte codes in a format suitable for inter- 

mined set of rules; and pretation; and 

based on the determination, selectively grant access to the using a processor of the integrated circuit card to use the 

requester to said one of the plurality of applications. 5 interpreter to interpret the application for execution; 

23. The integrated circuit card of claim 22, wherein the and 

predetermined rules provide a guide for determining using a communicator of the card when communicating 
whether said one of the plurality of applications accesses a between the processor and the terminal, 

predetermined region of the memory. 32. The method of claim 31, wherein the high level 

24. The integrated circuit card of claim 22, wherein the l° programming language format comprises a class file format, 
processor is further configured to: 33. The method of claim 31, wherein the processor 

authenticate an identity of the requester; and comprises a microcontroller. 

grant access to said one of the plurality of applications 34. The method of claim 31, wherein at least a portion of 
based on the identity. the memory is located in the processor. 

25. The integrated circuit card of claim 1, wherein the 15 35. The method of claim 31, wherein the high level 
processor is further configured to: programming language format comprises a Java program- 
interact with the terminal via the communicator to authen- mm 8 language format. 

ticate an identity; and 36 - T^ method of claim 31, wherein 

determine if the identity has been authenticated; and the application has been processed from a second appii- 

based on the determination, selectively allow communi- havin S a plurality of program elements, at least 

cation between the terminal and the integrated circuit one beio S a strm g of characters, further comprising: 

car ^ replacing the string of characters in the first application 

26. The integrated circuit card of claim 25, wherein the ™ ith an identifier. 

communicator and the terminal communicate via commu- 25 , 37 - The method of claim 36, wherein the identifier 
nication channels, the processor further configured to assign includes an integer. 

one of the communication channels to the identity when the 38 - The method of claim 31, further comprising: 
processor allows the communication between the terminal receiving a request from a requester to access an element 
and the integrated circuit card. of the card; 

27. The integrated circuit card of claim 26, wherein the 30 after receipt of the request, interacting with the requester 
processor is further configured to: to authenticate an identity of the requester; and 

assign a session key to said one of the communication based on the identity, selectively granting access to the 

channels, and element, 
use the session key when the processor and the terminal 39. The method of claim 38, wherein the requester com- 

communicate via said one of the communication chan- 35 prises the processor. 

nels. 40! The method of claim 38, wherein the requester com- 

28. The integrated circuit card of claim 1, wherein the prises the terminal. 

terminal has a card reader and the communicator comprises 41. The method of claim 38, wherein the element com- 
a contact for communicating with the card reader. prises the application stored in the memory, further com- 

29. The integrated circuit card of claim 1, wherein the 40 prising: 

terminal has a wireless communication device and the once access is allowed, using the application with the 
communicator a wireless transceiver for communicating requester. 

with the wireless communication device. 42. The method of claim 38, wherein the element com- 

30. The integrated circuit card of claim 1, wherein the prises another application stored in the memory, 
terminal has a wireless communication device and the 45 43. The method of claim 38, wherein the element includes 
communicator comprises a wireless transmitter for commu- data stored in the memory. 

nicating with the wireless communication device. 44. The method of claim 38, wherein the element com- 

31. A method for use with an integrated circuit card and prises the communicator. 

a terminal, comprising: 45. The method of claim 38, wherein the memory also 

storing an interpreter operable to interpret programs so stores an access control list for the element, the access 
derived from programs written in a high level program- control list furnishing an indication of types of access to be 
ming language and an application derived from a granted to the identity, further comprising: 
program written in a high level programming language based on the access control list, using the processor to 
format in a memory of the integrated circuit card selectively grant specific types of access to the 

wherein the application is derived from a program 55 requester. 

written in a high level programming language format 46. The method of claim 45, wherein the types of access 
by first compiling the program into a compiled form include reading data. 

and then converting the compiled form into a converted 47. The method of claim 45, wherein the types of access 
form, the converting step including at least one step include writing data. 

selected from a group consisting of 60 48. The method of claim 45, wherein the types of access 
recording all jumps and their destinations in the origi- include appending data. 

nal byte codes; 49. The method of claim 45, wherein the types of access 

converting specific byte codes into equivalent generic include creating data. 

byte codes or vice-versa; 50. The method of claim 45, wherein the types of access 

modifying byte code operands from references using 65 include deleting data. 

identifying strings to references using unique iden- 51. The method of claim 45, wherein the types of access 

tifiers; and including executing an application. 
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52. The meihod of claim 31, wherein the application is 
one of a plurality of applications stored in the memory, 
further comprising: 

receiving a request from a requester to access one of the 
applications stored in the memory; 

upon receipt of the request, determining whether said one 
of the plurality of applications complies with a prede- 
termined set of rules; and 

based on the determining, selectively granting access to 
the said one of the plurality of applications. 

53. The method of claim 52, wherein the predetermined 
rules provide a guide for determining whether said one of the 
plurality of applications accesses a predetermined region of 
the memory. 

54. The method of claim 52, further comprising: 
authenticating an ind entity of the requester; and 

based on the indentity, granting access to said one of the 
plurality of applications. 

55. The method of claim 31, further comprising: 
communicating with the terminal to authenticate an iden- 
tity; 

determining if the identity has been authenticated; and 
based on the determining, selectively allowing commu- 
nication between the terminal and the integrated circuit 
card. 

56. The method of claim 55, further comprising: 
communicating between the terminal and the processor 

via communication channels; and 
assigning one of the communication channels to the 
identity when the allowing allows communication 
between the card reader and the integrated circuit card. 

57. The method of claim 56, further comprising: 
assigning a session key to said one of the communication 

channels; and 

using the session key when the processor and the terminal 
communicate via said one of the communication chan- 
nels. 

58. A microcontroller comprising: 
a memory storing: 

a derivative application derived from an application 
having a class file format wherein the application is 
derived from an application having a class file format 
by first compiling the application having a class file 
format into a compiled form and then converting the 
compiled form into a converted form, the converting 
step including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; 

modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; and 

renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation, and 
an interpreter configured to interpret applications 

derived from applications having a class file format; 

and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 

59. The microcontroller of claim 58, further comprising: 
a communicator configured to communicate with a ter- 
minal. 



60. The microcontroller of claim 59, wherein the terminal 
has a card reader and the communicator comprises a contact 
for communicating with the card reader. 

61. The microcontroller of claim 59, wherein the terminal 
5 has a wireless communicator and a wireless transceiver for 

communicating with the wireless communication device. 

62. The microcontroller of claim 59, wherein the terminal 
has a wireless communication device and the communicator 
comprises a wireless transmitter for communicating with the 

to wireless communication device. 

63. The microcontroller of claim 58, wherein the class file 
format comprises a Java class file format. 

64. An integrated circuit card for use with a terminal, 
comprising: 

15 a communicator configured to communicate with the 
terminal; 
a memory storing: 

applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications derived 
from applications having a high level programming 
language format wherein the application is derived 
from a program written in a high level programming 
language format by first compiling the program into 
a compiled form and then converting the compiled 
form into a converted form, the converting step 
including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; 
modifying byte code operands from references using 
identifying strings to references using unique 
identifiers; and 
renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to communicate with the 

terminal. 

65. A microcontroller having a set of resource constraints 
50 and comprising: 

a memory, and 

an interpreter loaded in memory and operable within the 
set of resource constraints, the microcontroller having: 
at least one application loaded in the memory to be 
55 interpreted by the interpreter, wherein the at least one 
application is generated by a programming environ- 
ment comprising: 

a) a compiler for compiling application source pro- 
grams written in high level language source code 

60 form into a compiled form, and 

b) a converter for post processing the compiled form 
into a minimized form suitable for interpretation 
within the set of resource constraints by the 
interpreter, wherein the converter comprises means 

65 for translating from the byte codes in the compiled 

form to byte codes in a format suitable for interpre- 
tation by the interpreter by: 
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a) using at least one step in a process including the 
steps: 

a. I) recording all jumps and their destinations in 
the original byte codes; 

a.2) converting specific byte codes into equiva- 
lent generic byte codes or vice-versa; 

a.3) modifying byte code operands from refer- 
ences using identifying strings to references 
using unique identifiers; and 

a.4) renumbering byte codes in the compiled 
form to equivalent byte codes in the format 
suitable for interpretation; and 

b) relinking jumps for which destination address is 
effected by conversion step a.l, a.2 t a.3, or a.4. 

66. The microcontroller of claim 65, wherein the com- 
piled form includes attributes, and the converter comprises 
a means for including attributes required by the interpreter 
while not including the attributes not required by the inter- 
preter. 

67. The microcontroller of claim 65 wherein the compiled 
form is in a standard Java class file format and the converter 
accepts as input the compiled form in the standard Java class 
file format and produces output in a form suitable for 
interpretation by the interpreter. 

68. The microcontroller of claim 65 wherein the compiled 
form includes associating an identifying string for objects, 
classes, fields, or methods, and the converter comprises a 
means for mapping such strings to unique identifiers. 

69. The microcontroller of claim 68 wherein each unique 
identifier is an integer. 

70. The microcontroller of claim 68 wherein the mapping 
of strings to unique identifiers is stored in a string to 
identifier map file. 

71. The microcontroller of claim 65 where in the high 
level language supports a first set of features and a first set 
of data types and the interpreter supports a subset of the first 
set of features and a subset of the first set of data types, and 
wherein the converter verifies that the compiled form only 
contains features in the subset of the first set of features and 
only contains data types in the subset of the first set of data 
types. 

72. The microcontroller of claim 65 wherein the applica- 
tion program is compiled into a compiled form for which 
resources required to execute or interpret the compiled form 
exceed those available on the microcontroller. 

73. The microcontroller of claim 65 wherein the compiled 
form is designed for portability on different computer plat- 
forms. 

74. The microcontroller of claim 65 wherein the inter- 
preter is further configured to determine, during an inter- 
pretation of an application, whether the application meets a 
security criteria selected from a set of rules containing at 
least one rule selected from the set: 

not allowing the application access to unauthorized por- 
tions of memory, 

not allowing the application access to unauthorized 
microcontroller resources, 

wherein the application is composed of byte codes and 
checking a plurality of byte codes at least once prior to 
execution to verify that execution of the byte codes 
does not violate a security constraint. 

75. The microcontroller of claim 65 wherein at least one 
application program is generated by a process including the 
steps of:. 

prior to loading the application verifying that the appli- 
cation does not violate any security constraints; and 
loading the application in a secure manner. 



76. The microcontroller of claim 75 wherein the step of 
loading in a secure manner comprises the step of: 
verifying that the loading identity has permission to load 
applications onto the microcontroller. 
5 77. The microcontroller of claim 75 wherein the step of 
loading in a secure manner comprises the step of: 
encrypting the application to be loaded using a loading 
key. 

78. A method of programming a microcontroller having a 
10 memory and a processor operating according to a set of 

resource constraints, the method comprising the steps of: 
inputting an application program in a first programming 
language; 

j 5 compiling the application program in the first program- 
ming language into a first intermediate code associated 
with the first programming language, wherein the first 
intermediate code being interpretable by at least one 
first intermediate code virtual machine; 

20 converting the first intermediate code into a second inter- 
mediate code, wherein the step of converting com- 
prises: 

at least one of the steps of: 

a) recording all jumps and their destinations in the 
25 original byte codes; 

b) converting specific byte codes into equivalent 
generic byte codes or vice-versa; 

c) modifying byte code operands from references 
using identifying strings to references using 

30 unique identifiers; and 

d) renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 

relinking jumps for which destination address is effected 
35 by conversion step a), b), c), or d); 

wherein the second intermediate code is interpretable 
within the set of resource constraints by at least one 
second intermediate code virtual machine; and 
loading the second intermediate code into the memory of 
the microcontroller. 

79. The method of programming a microcontroller of 
claim 78 wherein the step of converting further comprises: 

associating an identifying string for objects, classes, 

fields, or methods; and 
mapping such strings to unique identifiers. 

80. The method of claim 79 wherein the step of mapping 
comprises the step of mapping strings to integers. 

81. The method of claim 80 wherein the step of loading 
50 the second intermediate code into the memory of the micro- 
controller further comprises checking the second interme- 
diate code prior to loading the second intermediate code to 
verify that the second intermediate code meets a predefined 
integrity check and that loading is performed according to a 

55 security protocol. 

82. The method of claim 81 wherein the security protocol 
requires that a particular identity must be validated to permit 
loading prior to the loading of the second intermediate code. 

83. The method of claim 81 further characterized by 
60 providing a decryption key and wherein the security proto- 
col requires that the second intermediate code is encrypted 
using a loading key corresponding to the decryption key. 

84. An integrated circuit card for use with a terminal, 
comprising: 

55 a communicator configured to communicate with the 
terminal; 
a memory storing: 



40 



45 



08/21/2003, EAST Version: 1.04.0000 



US 6,308,317 Bl 



27 



28 



10 



15 



20 



an application derived from a program written in a high 
level programming language format wherein the 
application is derived from a program written in a 
high level programming language formal by first 
compiling the program into a compiled form and 
then converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references using 

identifying strings to references using unique 

identifiers; 

recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 
an interpreter operable to interpret such an applica- 
tion derived from a program written in a high level 
programming language format; and 
a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the application 
for execution and to use the communicator to commu- 
nicate with the terminal. 

85. A method for use with an integrated circuit card and 25 
a terminal, comprising: 

storing an interpreter operable to interpret programs 
derived from programs written in a high level program- 
ming language and an application derived from a 
program written in a high level programming language 
format in a memory of the integrated circuit card 
wherein the application is derived from a program 
written in a high level programming language format 
by first compiling the program into a compiled form 
and then converting the compiled form into a converted 
form, the converting step including: 
modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; and 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for inter- 
pretation; 

using a processor of the integrated circuit card to use the 
interpreter to interpret the application for execution; 
and 

using a communicator of the card when communicating 
between the processor and the terminal. 

86. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to communicate with the 
terminal; 
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a memory storing: 

applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications 
derived from applications having a high level 
programming language format wherein the appli- 
cation is derived from a program written in a high 
level programming language format by first com- 
piling the program into a compiled form and then 
converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references 

using identifying strings to references using 

unique identifiers; 
recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to communicate with the 

terminal. 
87. A microcontroller comprising: 
a memory storing: 

a derivative application derived from an application hav- 
ing a class file format wherein the application is derived 
from an application having a class file format by first 
compiling the application having a class file format into 
a compiled form and then converting the compiled 
form into a converted form, the converting step includ- 
ing: 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; and 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation, and 

an interpreter configured to interpret applications 
derived from applications having a class file format; 
and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 
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